SailPointのアイデンティティ・プラットフォームとIdentityNowの違い
IdentityNow
1 SaaS-based identity governance platform
2 機能：
a プロビジョニング provisioning
b アクセス権申請・付与 access requests
c パスワード管理 password management
d アクセス権の棚卸 access certification
e 職務分掌/ポリシー管理 separation-of-duties
SailPoint Identity Platform
1 incorporates AI and machine learning into the core IdentityNow platform
2 機能
a アクセス権インサイト Access Insights
b アクセスのロール権限定義 Access Modeling
c レコメンデーションエンジン Recommendation Engine
d マルチクラウドアクセス管理 Cloud Governance
０、用語集
entitlement 権限、例：特定入室権限、ファイルアクセス権限、フォルダーアクセス権限
access profile アクセス権限集（複数権限の集合、例Admin, Guest）
role 役割・ロール
certification 棚卸
source 3rdパーティーのアプリケーションやDBなどのユーザー
１、プロビジョニング
プロビジョニングとは
プロビジョニングとは、必要なシステムやアプリケーションに対し、ユーザーアカウントの作成、変更、削除を行うことです。高度なプロビジョニングソリューションの場合、ユーザー属性のみにとどまらずアクセス権限も含めて管理し、アカウントを利用用途や業務上の役割に応じて運用し、IT部門の負荷軽減や管理業務の自動化に寄与します。
概要：
アプリケーションへの適切なアクセス権を自動で設定
機能：
a プロビジョニングの⾃動化
IT部門のプロビジョニング作業は、各種アプリケーションに対する権限をロール（役割）ごとに付与する設定を事前にしておくことで、SailPoint IdentityNowが採用や退職等の人事情報の変更を検知し、役割に応じた権限を自動でプロビジョニングします。
b 権限の⾃動更新
権限の⾃動更新は、ユーザーの⼈事異動や役職変更などの⼈事イベントが発⽣した際、SailPoint IdentityNowで⾃動的に各アプリケーションに適切な権限変更を⾏う機能です。
企業では退職したユーザーのIDが各アプリケーションにログイン可能な状態で放置されていることも少なくありません。
インターネット技術においてサービス化はすごい勢いで進んでいます。
IaaS、BaaS、PaaS、SaaS、ウェブサービス、クラウドサービス、マイクロサービスなどなど、毎日目に触れるようになっています。
当たり前の話かもしれないが、本当にその本質を理解するには、あまり簡単なことではありません。
ここでは、自分がサービス化に対する理解と、アマゾンの事例を交えて説明してみようと思います。
抽象的な話なので、分かりづらいと思いますが、すみません。
まず2002年。（当然このことを知ったのは、下記記事が発表されたの2011年10月以降のことです）
Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した（前編）から引用
それである日 Jeff Bezos が指令を出した。まあ彼がいつもやってることなんだけど。その度にみんなはピコピコハンマーで叩かれるありんこみたいに走り回るんだ。でもそのある一度、2002年かそのくらいのことだったと思うけれど、彼は指令を出した。とんでもなく巨大で、目の玉が飛び出るほど重たいやつを。普段の指令が頼んでも無いボーナスに思えるようなやつを。
彼の巨大な指令はこんな感じだった。
1)この時点より、全てのチームはサービスインターフェースを通じて全てのデータと機能を公開すること。
2)各チームは各々そのインターフェースを通じて通信しなければならない。
3)その他の全てのプロセス間通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを読むこと、メモリ共有モデル、バックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを経由した通信だけが許可される。
4)使用する技術は問わない。 HTTP 、 Corba 、 Pubsub 、 カスタムプロトコル、何でも良い。 Bezos は気にしない。
5)全てのサービスインターフェースは、例外なく、外部に公開可能なようにゼロから設計されなければならない。すなわち、チームは全世界のデベロッパに向けてインターフェースを公開することができるよう、設計し、計画しなければならない。例外は無い。
6)そうしない者は解雇される。
7)ありがとう！良い一日を！
中略
それでも、6番は、本当だった。だからみんな一生懸命会社に行った。 Bezos は、さらに上級のチーフ熊ブルドッグであるところの Rick Dalzell に率いられた数人のチーフブルドッグを雇って、成果と進行を監視させた。 Rick は元レンジャーで、陸軍士官学校出身で、元ボクサーで、元 WalMart で拷問のような削減をやってのけた人物で、デカくて愛想の良い、「堅牢なインターフェース」という言葉を連呼する男だった。 Rick は歩き回り、「堅牢なインターフェース」について語り回り、そして言うまでも無く、みんなたくさんの進展をし、 Rick にそれを知らせた。
それからの数年間、 Amazon 内部はサービス指向アーキテクチャに姿を変えていった。その変化を形にしている間に、彼らは非常に多くのことを学んだ。 SOA に関する学問や論文は当時もいくつかあったけれど、 Amazon のとんでもない規模からすれば、そんなもの、インディ・ジョーンズに向かって「通りを渡るときは左右をよく見るんだよ」って言うくらいの意味しかない。 Amazon の開発スタッフはその途上でとにかくたくさんの発見をした。
AWSクラウドデザインパターン
Azure アーキテクチャ センター クラウドの設計パターン
Azure Architecture Cloud Design Patterns
Azure 体系结构 云设计模式
どちらもデザインパターンのドキュメント集ですがAzureの方がよりモダンでコンテナ寄りです。
とは言っても今までのノウハウをうまくまとめたにすぎないです。
それから、AWSの方がTips集っぽくてちょっと古臭いです。
Sidecarなど、Azureは元々GoogleのDesign patterns for container-based distributed systems論文を引用しましたね。
しかし以下で全部なめてみたところは、別にクラウドだからこそのパターンがほとんどありませんでした。